feat: add mcpplibs.grpc 1.83.0 (Form A, grpc-m) - #151

The end of the gRPC track that #147 (abseil, protobuf), #148 (re2, the protobuf
`upb` feature) and #149 (c-ares) built toward. gRPC itself lands as a Form A
descriptor pointing at mcpplibs/grpc-m.

WHY THIS ONE CANNOT BE A COMPAT DESCRIPTOR. Every other heavy library here
points at an upstream tarball. gRPC publishes none: v1.83.0 has no release
assets at all, and its tag archive carries abseil, protobuf, re2, boringssl and
zlib as EMPTY submodule placeholders — one directory entry each — so there is
nothing for url+sha256 to address. grpc-m's release tarball IS that artifact:
upstream's src/ and include/ vendored with zero patches, plus the two
third_party pieces gRPC really ships (address_sorting, xxhash).

What it does NOT vendor is why it belongs on this index rather than standing
alone: abseil, protobuf(+upb), re2, c-ares, OpenSSL and zlib all come from the
packages here, so a consumer that also uses protobuf or abseil directly links
ONE copy instead of colliding with a second vendored set.

No CMake, no Bazel, no configure step — checked, not assumed: gRPC's tree
contains no .h.in or config.h.cmake, and its generated upb code is checked in
upstream, so mcpp needs only include paths. All 1001 TUs are compiled by the
resolved toolchain, so nothing inherits a foreign C++ ABI the way an
install()-driven CMake build would (which is what ruled that route out for
gRPC in the first place).

The source list is upstream's own — the union of add_library(gpr), grpc, grpc++
and address_sorting — and grpc-m's tools/gen_sources.py --check runs in that
repo's CI to prove the manifest has not drifted from the vendored tree. One file
is excluded: src/core/ext/upb-gen/google/protobuf/descriptor.upb_minitable.c,
byte-for-byte identical to the bootstrap copy compat.protobuf's `upb` feature
compiles.

LINUX + MACOS ONLY, and the reason is a dependency rather than gRPC:
compat.openssl has no windows xpm entry, so resolution there fails with
E_NOT_FOUND before anything compiles, and gRPC's secure build cannot drop TLS.
The member is gated the way tests/examples/openssl already is — cfg-gated
dependency, no-op main() on windows. #150 is the fix for the underlying gap.

The member drives `import grpc;` only and carries no protoc output: gRPC's
codegen needs host tools mcpp cannot hand a consumer, so grpc-m's own
examples/helloworld covers the generated-stub path while this member covers the
module surface. It asserts the error path too (a Status that is NOT ok), so an
always-OK stub could not pass.

Verified with the pinned mcpp 2026.8.3.3, gcc@16.1.0, MCPP_BUILD_CACHE=local,
target/ and .mcpp/ removed first — the package downloads from the descriptor's
real release tarball and sha:

  Compiling mcpplibs.grpc v1.83.0
  grpc::Version() = 1.83.0
  grpc module: OK
  test result ok. 1 passed; 0 failed; finished in 247.85s

grpc-m's own CI is green on both platforms for the tagged commit (linux 54m21s,
macOS 29m49s), where examples/helloworld stands a real server on a loopback
port and makes a real unary RPC. CN mirror published and closed-loop checked:
mcpp-res/grpc@1.83.0 returns http=200 and is byte-identical to GLOBAL.